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REMARKS 

The Examiner rejected claim 113 under 35 U.S.C. §112, first paragraph, as allegedly 
failing to comply with the written description requirement. To expedite prosecution of the 
present application, applicants amended the preamble of independent claim 1 1 3 to recite "[a] 
computer program product comprising computer program code adapted to perform: ..." Support 
for the amendment is provided, for example, at 2, paragraph 25 of the published application (US 
2005/0169208). 

The Examiner rejected claims 77-79, 101-103, 106 and 1 13 under 35 U.S.C. § 102(b) as 
being anticipated by PCT Publication No. WO 00/78080 to Sevanto et al The Examiner 
rejected claims 80 and 104 under 35 U.S.C. §103(a) as being unpatentable over Sevanto in view 
of U.S. Patent No. 6,230,005 to Le et al, rejected claims 81 and 105 under 35 U.S.C. § 103(a) as 
being unpatentable over Sevanto in view of U.S. Publication No. 2001/0053126 to Chen, 
rejected claims 82 and 107 under 35 U.S.C. §103(a) as being unpatentable over Sevanto in view 
of PCT Publication No. WO 01/47179 to Uskela et al, and rejected claims 82 and 108 under 35 
U.S.C. § 103(a) as being unpatentable over Sevanto in view of U.S. Publication No. 
2002/0002041 to Lindgren. 

Applicants amended independent claim 101 to recite, similarly to the recited language in 
independent claims 77 and 113, that the information for the selected packet data protocol context 
is for signaling traffic. 

Applicants' independent claim 77 recites, inter alia, "transmitting a second data protocol 
request from the first network element to a second network element, the second packet data 
protocol request including at least part of the first packet data protocol request; receiving from 
the second network element, information on a selected packet data protocol context for signalling 
traffic." Thus, a second network element sends the first network element information on a 
selected PDP context for signaling traffic, e.g., information such as whether a dedicated 
signaling PDP context has been established or nor: 

[0058] In accordance with known techniques, once the PDP context is activated, the 
GGSN 14 transmits a Reply (Accept) message 54 back to the SGSN 12, which in turn 
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transmits a Reply (Accept) message 56 to the UE 10. 

[0059] In accordance with a preferred embodiment of the present invention, the Reply 
(Accept) messages are modified or extended to include an indication of the PDP context 
established. That is, the messages include an indication of whether the dedicated 
signalling POP context has been established. This can be done in a number of ways. 

[0060] One embodiment for communicating the PDP context status to the UE is shown in 
FIG. 3(a), in which the Reply (Accept) messages include the protocol configuration 
options (PCO) including the signalling flag. The GGSN sets the signalling flag in the 
Reply (Accept) message 54 to indicate that the dedicated signalling PDP context has been 
established, and the SGSN copies the signalling flag to the Reply (Accept) message 56. 
In this way, the setting of the signalling flag in the Reply (Accept) message indicates to 
the UE whether the dedicated signalling PDP context has been established or whether the 
general purpose POP context has been established. 

[0063] In a second embodiment, when the GGSN receives the Create PDP Context 
Request with the signalling flag set, and the network does not support dedicated 
signalling POP contexts, the POP context is rejected by the GGSN. In 3 GPP R5 there is 
an existing cause code: "Service Not Supported". This cause code could be returned to 
the UE. This is illustrated in FIG. 3(c). However, this does not give the UE information 
that it is the dedicated signalling PDP context that the network does not support. After 
receiving the PDP context rejection, the UE may need to initiate a POP context 
requesting the general purpose PDP context in order to proceed if such PDP context does 
not already exist. 

[0064] For both the first and second embodiments described hereinabove, the present 
invention preferably further provides a new cause code for transmission to the UE. Such 
cause code may, for example, be: "Dedicated Signalling PDP Context not Supported". 
Preferably this cause code is transported transparently through the SGSN, using the 
protocol configuration options (PCO). Alternatively the cause code may be carried from 
the GGSN to the SGSN, and from the SGSN to the UE, as is illustrated in FIG. 3(d). (US 
2005/0169208, pages 3-4, paragraphs 58-64) 



In rejecting claim 77, the Examiner stated: 

Regarding claim 77, Sevanto '080 discloses ... 

receiving from the second network element (page 9, lines 5-6 of Sevanto '080 
disclose the GGSN sending a Create PDP Context Response message back to 
the SGSN), information on a selected packet data protocol context for signaling 
traffic (page 8, line 33 - page 9, line 2 of Sevanto '080 disclose the GGSN 
establishing a tunnel based on the service attributes of the PDP Context Request 
message)" (Emphasis in the original, Final Action, pages 4-6) 



Applicants respectfully disagree with the Examiner's contentions. 

Sevanto describes a method and an arrangement provided for indicating the specific use 
of a packet-switched communication connection between a mobile station and a fixed packet- 



-7- 



Appln. No. 10/520,675 
Filed: April 6, 2005 



Attorney's Docket No.: 39700-581N01US/NC16969US 
Customer Number: 64046 



switched data transmission network (Sevanto, Abstract). In describing the exchange of messages 
between a mobile station (MS), a Serving GPRS Support Node (SGSN) and a Gateway GPRS 
Support Node (GGSN) through a Base Station Subsystem (BSS), Sevanto explains that the 
GGSN receives a message and recognizes from the message's indicator which specific service 
type is involved. Sevanto further explains that the GGSN then decides, based on the APN and/or 
the PDP, whether to provide the service itself or select an external service provider, and sends a 
Create PDP Context Response message to the SGSN: 

At step 206 the GGSN receives the message and recognizes from the indicator according 
to the invention which specific service type is involved. The GGSN decides to provide 
the service by itself or to select an external service provider based on the APN and/or the 
PDP Configuration Options field in the context activation request. The GGSN creates an 
association with the service attributes and the established tunnel (identified by TID 
consisting of the user's IMSI and the NSAPI value of the PDP context) 

After the service has been activated and possibly some service-related parameters have 
been configured (e.g. according to the information delivered in the Protocol 
Configuration Options information element), the GGSN sends at step 207 a Create PDP 
Context Response message to the SGSN, which receives it at step 208. The structure and 
contents of the message may be the same as in prior art Create PDP Context Response 
messages: the object of letting both the SGSN and the GGSN know the specific service 
type identifier has been accomplished through the use of the Activate PDP Context 
Request and Create PDP Context Request messages explained above. At step 209 the 
SGSN transmits an Activate PDP Context Accept message to the MS. The reception 210 
of this message at the MS finalizes the context activation. No PDP address need to be 
assigned for the context, although such an assignment is not precluded by the invention. 
After step 210, there is a logical tunnel in place between the MS and the GGSN, where 
use of the specific service using the activated PDP context may be made as illustrated by 
block 211. 

(Emphasis added, Sevanto, page 8, line 33, to page 9, line 16) 



Thus, the Create PDP Context Response message may have a structure and content to, for 
example, enable the SGSN and the GGSN know the specific service type identifier. Sevanto, 
however, does not describe that any of the GGSN or the SGSN (or any other network element) 
sends or receives information regarding a PDP context for signaling traffic. Accordingly, 
Sevanto fails to disclose or suggest at least the features of "receiving from the second network 
element, information on a selected packet data protocol context for signalling traffic," as recited 
by independent claim 77. 

Independent claim 77, and the claims depending from it, are therefore patentable over the 
cited art. 
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Applicants' independent claims 101 and 113 recite "said receiver configured to receive 
from the second network element information on a selected packet data protocol context for 
singnalling t raffic between the user equipment and the network," or similar language. For 
reasons similar to those provided with respect to independent claim 77, applicants' independent 
claims 101 and 1 13, and the respective claims depending from them, are patentable over the 
cited art. 

Additionally, claim 78, depending from claim 77, recites "wherein the second packet data 
protocol request includes the identity of the preferred packet data protocol context, wherein the 
second network element selects the packet data protocol context in dependence on the preferred 
packet data protocol context and the packet data protocol contexts supported by the network." 
Thus, in selecting the PDP context to be established, both the preferred PDP context indicated by 
the user equipment and the available PDP contexts supported by the network are taken into 
account. 

In rejecting claim 78, the Examiner stated: 

Regarding claim 78, Sevanto '080 discloses the method of claim 77, wherein the 
second packet data protocol request includes the identify of the preferred packet 
data protocol context (page 8, lines 14 - 17 of Sevanto '080 disclose the GGSN 
using the QoS requested by the mobile station to determine the QoS for the 
connection), wherein the second network element selects the packet data 
protocol context in dependence on the preferred packet data protocol context 
(page 8, lines 14-17 of Sevanto '080), and the packet data protocol contexts 
supported by the network (page 8, lines 15-17 of Sevanto '080 disclose the 
GGSN can restrict/negotiate QoS, which is stored in the PDP context, due to the 
system being overloaded, therefore certain QoS cannot be supported by the 
network). (Final Action, pages 6-7) 



Applicants respectfully disagree with the Examiner's contentions. 
The passage in Sevanto references by the Examiner in relation to the rejections of claim 
78 provides: 

• The QoS Negotiated field 315 indicates the result of a QoS negotiation between 
the MS and the SGSN. It is not downwards binding to the GGSN, meaning that 
the GGSN is allowed to further restrict the QoS given its capabilities and the 
current load. 

• The TID or Temporary identifier 3 17 is composed by the SGSN for the 
requested PDP Context by combining the IMSI (International Mobile Subscriber 
Identifier) stored in the MM context (Mobility Management contex) of the MS 
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and the NSAPI received in field 301 of the Activate PDP Context Request 
message. 

(Sevanto, page 8, lines 14-19) 

While Sevanto describes QoS negotiation between the MS and SGSN, and a temporary 
identifier composed for a requested PDP context, nothing in the above passage describes that a 
PDP context is selected based on the context preferred (or requested) by a user equipment and 
the available contexts supported by the network. Accordingly, contrary to the Examiner's 
contentions, Sevanto also fails to disclose or suggest at least the features of "wherein the second 
network element selects the packet data protocol context in dependence on the preferred packet 
data protocol context and the packet data protocol contexts supported by the network," as recited 
by claim 78. 
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CONCLUDING COMMENTS 



It is believed that all of the pending claims have been addressed in this paper. However, 
failure to address a specific rejection, issue or comment, does not signify agreement with or 
concession of that rejection, issue or comment. In addition, because the arguments made above 
are not intended to be exhaustive, there may be reasons for patentability of any or all pending 
claims (or other claims) that have not been expressed. Finally, nothing in this paper should be 
construed as an intent to concede any issue with regard to any claim, except as specifically stated 
in this paper, and the amendment of any claim does not necessarily signify concession of 
unpatentability of the claim prior to its amendment. Applicants ask that all claims be allowed. 

If there are any questions regarding these amendments and remarks, the Examiner is 
encouraged to contact the undersigned at the telephone number provided below. The 
Commissioner is hereby authorized to charge any additional fees that may be due, or credit any 
overpayment of same, to Deposit Account No. 50-0311, Reference No. 39700-581N01US/ 
NC16969US. 



Address all written correspondence to 

Mintz, Levin, Conn, Ferris, Glovsky and Popeo, P.C. 

One Financial Center 

Boston, Massachusetts 021 1 1 

Customer No. 64046 

Telephone: 617-348-1806 

Facsimile: 617-542-2241 
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Respectfully submitted, 




Reg. No. L0080 
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